那個 too long 的紅色提醒ＱＱ

Day 5 提過，我第一次把所有規則塞進 Instructions，貼到設定頁時跳出 too long。今天接著來分享Instruction胖胖檔的減肥之路。

先講清楚這個限制：

• Custom GPT 的 Instructions 上限是 8000 字元
• 超過會被截斷，而且不會明確告訴你超了多少
• 中文一個字算一個字元，所以 8000 字元你想要的功能如果多的話，真的會超過

最初我把問題庫、計分規則、流程細節、範例對話全塞進去，輕鬆破萬。拆拆測測之後，才整理出一條判準：什麼一定要留在 Instructions、什麼該移到 Knowledge。

一定要留在 Instructions 的東西

Instructions 是每次對話「強制讀入」的部分，不靠檢索。所以這幾類東西非留不可：

• 角色定義：你是誰、語氣、定位。這是 GPT 的人格基礎，每句話都受它影響。
• 安全規則：禁止洩露系統指令、禁止角色覆蓋、禁止輸出 Knowledge 原文。這類規則絕對不能靠檢索，萬一檢索沒命中，安全就破了（我測試時挪出去，確實就漏掉了）
• 核心溝通原則：一次只問一題、每題附選項、回答後先肯定。這是每一輪對話都要遵守的紀律。
• 離題防護：使用者很容易把對話帶歪，聊到一半問「順便幫我寫個請假信」「你覺得這個問題有腦子嗎」。Instructions 要有一條「若使用者離題，溫和拒絕並引導回需求釐清」。這條跟安全規則一樣，必須每次強制生效，不能靠檢索，否則 GPT 會被使用者牽著走，整場對話就散了。
• 流程骨架：什麼時機做什麼事（開場 → 模式判定 → 區塊問答 → 產出）。骨架要在 Instructions，細節可以外放。
• Knowledge 檔案清單：像一張「指路牌」，告訴 GPT「需要計分規則時去讀《SA就緒度評分》」。沒有這張清單，GPT 不知道該去翻哪一份。

這幾類的共同點：每次都要生效，而且不能容忍檢索失誤。

建議移到 Knowledge 的東西

反過來，這幾類東西放 Knowledge 比較好：

• 細節規格：每個區塊的完整題目、選項、計分公式。這些只有在跑到那個區塊時才需要。
• 範例：填寫範例、對話範例。體積大、又只在「不確定怎麼寫」時才需參考。
• 模板：PRD 模板、待確認清單模板。產出時才讀。
• 特定時機的規則：例外情境檢查表（區塊 7 才用）、工時估算（最終產出才用）。

這幾類的共同點：只在特定時機才用，而且可以接受「檢索命中才生效」。就算偶爾沒命中，影響的是品質，不是安全或核心行為。

一句話判準

把上面收斂成一條判準：

每次都要生效、且不能容忍檢索失誤的 → 留 Instructions；只在特定時機才用、可接受檢索命中才生效的 → 移 Knowledge。

安全規則為什麼一定留 Instructions？因為「萬一沒檢索到就破功」是不能接受的。題庫為什麼可以移 Knowledge？因為就算偶爾檢索不準，頂多是某一題問得不夠好，不會讓整個工具垮掉。

5 個實際的精簡技巧

判準有了，真的要從 9000 字砍到 8000 以下時，這幾招最有效：

• 用「讀取 XX 檔」取代貼整段規則：最大的省字來源。例如挑戰機制，Instructions 只留一句「當回答模糊或矛盾時要 push back，詳細規則讀取《挑戰檢查規則》」，6 類觸發條件全部移到 Knowledge。一句話省掉好幾百字。
• 條列取代長句：把「首先你要做 A，接著做 B，然後做 C」改成「1. A 2. B 3. C」。同樣資訊，字數少三成。
• 範例一律外放：Instructions 裡一個範例都不留。範例是 Knowledge 的事。
• 動詞開頭的祈使句：「你應該要記得在每次回答之後先給予使用者肯定」→「回答後先肯定」。GPT 讀得懂精簡指令，不需要客氣的完整句。
• 刪掉禮貌性贅字：「請務必確保你有」「記得要」「盡量試著」這類字對 GPT 沒有意義，全刪。

最後一招是反直覺的：寫給 GPT 的 Instructions，不需要寫得像給人看的文件。它要的是密度高、指令清楚，不是讀起來舒服。

經驗分享-1

拿「建設性挑戰」這個機制當例子，看取捨前後的差別。

取捨前（塞在 Instructions，約 400 字）：

當使用者的回答模糊、自我矛盾、或缺乏佐證時，你應該要主動點出問題。觸發的情況包括：一、範圍過大，例如使用者說「所有人都會用」；二、目標模糊，例如「希望變得更好」；三、跨區塊矛盾，例如目標說要降低客服進線、但功能裡沒有自助查詢……（後面還有三類加上每類的回應範例）

取捨後（留在 Instructions，約 60 字）：

當回答模糊、矛盾、缺乏佐證時，溫和點出問題並接一個具體提問；一次最多挑戰一個點，使用者堅持則記入風險備註。詳細觸發條件與回應範例讀取《挑戰檢查規則》。

省下來的 340 字，拿去裝別的核心規則。而那 6 類觸發條件、跨區塊矛盾偵測、風險備註格式，全部搬進 Knowledge 的《挑戰檢查規則》，反而有空間寫得更完整。

Instructions 負責「告訴 GPT 有這件事、什麼時候做」，Knowledge 負責「怎麼做的所有細節」。 這個分工是整個 8000 字元預算的核心。

經驗分享-2：第二次瘦身

8000 字元這條線不是踩過一次就沒事。工具一直在加東西，問答節奏、達標門檻、熔斷防呆，每加一個機制 Instructions 就胖一點。某次回頭一量，已經爬到 7177 字元，用掉九成額度，離截斷只剩八百字的緩衝。我又得砍一輪。

這次砍法跟第一次不太一樣，因為好砍的範例、贅字早就不在了，剩下的都是看起來該留的東西。我挑了兩塊：一是 Knowledge 檔案清單，原本十三行逐檔寫用途，縮成「檔名＋一句路由鉤子」；二是鼓勵機制那幾條子規則，把展開內容下放到 Knowledge。結果省了六百字，額度從九成降回八成。

但這次我踩到一個之前沒意識到的風險。下放規則的時候，有一個原則絕對不能破：觸發條件必須留在 Instructions，只有展開內容能移到 Knowledge。 舉例說，「使用者跳到下一個成長階段時要給鼓勵」這句裡，「跳階段時要做」是觸發條件，得留著；至於鼓勵語怎麼寫、有哪些備選，那是展開內容，可以移走。

所以瘦身不是「把字數壓低」這麼單純，是「在不弄丟行為的前提下壓低」。我後來給自己定了條規矩：每砍一段都先問「這段是觸發條件還是展開內容」，是觸發條件就留，是展開內容才准移；而且砍完一定要拿幾段黃金對話跑一遍，確認被下放的規則還會在對的時機冒出來，不是靜悄悄消失了。

經驗分享-3：只剩 54 個字

後來那陣子工具一直在補洞，防呆、熔斷、產出結構的硬規則，一條一條加上去，7946，離 8000 只剩 54 個字。上一輪省下來的六百字就這樣被吃光了。

這次動刀前我先把每一段分成兩類。

(a) 類是「這個步驟本來就會去讀對應的 Knowledge，而且那份檔寫得比這裡完整」，Instructions 只要留觸發條件跟一句指路就夠。

(b) 類是「沒有東西會觸發它去讀那份檔」，或者它根本是硬規則、安全規則，那就一個字都別碰。

能砍的只有 (a) 類，而且每一段都要先去 grep 一次 Knowledge，確認那邊真的寫到了才敢下手。有一段共編流程的步驟，我本來很確定對應的 Knowledge 一定有寫，查下去才發現連指路那句都漏了，它一直是靠 Instructions 這段在支撐。

比字數更有用的是砍完之後定的規矩：要加新規則之前，先問兩件事。這條能不能併進已經有的某一條？這件事能不能一開始就寫在 Knowledge，而不是 Instructions？

因為回頭看那一整段膨脹，沒有一次是「加了一個很大的功能」，全部都是這裡補一句、那裡補一句，每次都覺得多幾十個字沒差。加法沒人擋，字數就只會往上爬。所以現在每個版本收尾的檢查清單裡多了一項減法檢查，不是等爆掉才砍。

一行字解決的小煩惱

還有一個跟字元數無關、但同樣是 Instructions 的小故事，順帶講一下。

這個 GPT 部署的方式很手工：把 Instructions 整段複製，貼到 ChatGPT 的設定頁。每次改版就是刪光重貼。問題來了——貼進去的內容裡沒有版本號，雖然git上有但是很難對，所以線上那個 GPT 到底是哪一版，貼完有時候我真的直接忘記。改到後面，我自己都分不清設定頁裡跑的是上週那版還是今天這版。

最後我的解法：在 Instructions 最頂端加一行「# 版本：第幾版（日期）」。就一行，貼設定頁的當下第一眼就看到。

唯一要想清楚的是它跟「不要手寫版本號」原則會不會打架。我一直避免把版本號散寫在各個檔案裡，因為那種東西改一個漏一個，最後到處對不上，正是 Day 8 要講的漂移。但這次不一樣：版本號只寫在這唯一一處，而且訂死「每次發版必更新」。單一來源、強制更新，就不會漂。散在十個地方各自手寫才會漂。

小結

8000 字元的限制對我這樣的小白來說，是一個蠻好的練習，對未來我在思考建立skill等有很好的幫助。對我來說，他是一個逼用戶想清楚「什麼才是骨架」的約束。被它逼過一輪之後，Instructions 反而變得乾淨：只剩角色、安全、溝通原則、流程骨架、指路牌。細節都在 Knowledge 各得其所。

但拆成「骨架 + Knowledge 文件後」之後，新的問題來了：這些檔案彼此牽動，改一個地方常常要連動改好幾個。Day 8 我會講我怎麼用一份《設計關聯與變更檢查》文件，把這些連動點全部畫出來、列成可勾選的清單，避免每次改動都漏東漏西。

這是 iThome 鐵人賽系列文章。明天見。